Build the shared Base UI control family - #86

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Reviewed head b31a9a8d93352569ba2a7f49ad2c584e16ce5af4 against base f3c9be6ce79decace5c384366710bd69d301ca2e.

Changes requested

P2: Route Textarea’s control props through Field.Control

src/shared/design-system/ui/Textarea.tsx:8-11

All caller props are placed on the rendered <textarea>, leaving Base UI unaware of its explicit id. For example, <Field label="Notes"><Textarea id="notes-control" /></Field> renders a label targeting Base UI’s generated control ID, while the actual textarea has id="notes-control". Clicking the label does not focus the field in either Chromium or WebKit. aria-labelledby still supplies an accessible name, so the existing role-query/typing test misses the broken native association.

Pass the relevant control props to BaseField.Control, leaving textarea-specific attributes on its rendered element as needed, and add coverage for an explicit ID with label-click focus. Preserve refs and controlled edits while doing so.

P2: Keep uncontrolled choice state consistent after form reset

src/shared/design-system/ui/Checkbox.tsx:17-23 and src/shared/design-system/ui/RadioGroup.tsx:12

The new wrappers expose defaultChecked / defaultValue and native form participation, but the installed Base UI 1.7.0 path leaves visible state and submitted values inconsistent after a native reset. Reproduction: start with a checked checkbox and radio value a, uncheck the checkbox and choose b, then activate a native <button type="reset">. In both Chromium and WebKit, the visible/ARIA state remains unchecked and b, while new FormData(form) contains the checked checkbox and a.

This is a dependency behavior exposed by the new shared controls, not a production feature regression at this layer. Resolve reset synchronization at the primitive boundary (including an upstream fix if appropriate) and add a regression that checks both visible checked state and FormData after reset. The current ordinary-change test does not exercise reset.

P2: Keep the new invalid field outline above 3:1

src/shared/design-system/styles/forms.css:42-44

The new invalid-state rule replaces the normal control outline with --border-danger. In light mode, both browser engines resolve this to rgb(235, 142, 144) against the field’s white --surface-panel, only 2.385:1. Since the field fill is also the panel fill, that border is the visible control boundary; the error text does not restore its visibility. This fails the documented 3:1 requirement in DESIGN.md:256-261.

The token defect is inherited from #85 and already reported there; #86 introduces its actual Input/Textarea consumption. Resolve the shared role in the foundation and bring that correction through the stack rather than adding a local palette override. Cover the rendered invalid boundary in both themes.

Validation and scope

• Focused browser probes at the reviewed head used the real shared components and both host/viewer CSS entry points in Chromium and WebKit. Loading blocked pointer, Enter/Space and implicit submission; re-enabling produced one action and one submission with unchanged button dimensions. Search clearing restored input focus. The explicit-ID textarea failure and invalid-border colors reproduced in both engines.
• The new form CSS is not imported by the host at #86, but these wrappers have no feature consumers in this snapshot and #88 explicitly adds the import when adopting them. This is a stack integration dependency, not an additional blocker here. The deliberate shared radius/size changes are not being treated as regressions merely because old assertions changed.
• Hosted JavaScript and both Chromium shards passed. WebKit shard 1/2 failed in navigation-scroll-intent.spec.mjs on a relay-stream access-control console error (fixture.mjs:1027); I have not established causation from this diff. CI remains red. Broad CI-equivalent suites and native visual testing were not rerun locally.

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Reviewed head b91c8fbb6d5d1cc4fa9cf876ff3e79a02d26268a against stacked base 27dd5d0d590943abe748c5c25b9b423d33ed67a2 (#85, not main).

Changes requested

P2: Isolate the new control radius from unmigrated host controls

src/shared/design-system/styles/tokens.css:641 changes --radius-control from var(--corner-control) (12px at the default scale) to 0.5rem (8px). That is intentional for the new shared controls, but the unchanged host bridges still map both --radius-legacy-control and Tailwind’s --radius-xl to it (src/shared/styles/tokens.css:46, src/shared/styles/globals.css:56). Unmigrated native buttons and rounded-xl controls therefore also change from 12px to 8px.

This affects real legacy consumers, including the profile inputs at src/features/communities/ProfileFields.tsx:24,38 and plugin-folder choices at src/app/PluginImport.tsx:190. The unchanged compatibility contract explicitly preserves existing native-control recipes and separates the old control radius (docs/design-system.md:138-145). This is distinct from the intended geometry changes to shared Button/fields.

The existing reproduction is the browser case “compiled host preserves compatibility utility meanings”: its #old-primary native button uses rounded-xl. This PR changes that compatibility expectation from 12px to 8px at tests/browser/appearance.spec.mjs:276-279, accepting the leak rather than preserving the old surface.

Smallest fix: retain the shared 8px radius, point the host’s legacy radius at the retained --corner-control value, route its legacy rounded-xl mapping through that legacy radius, and restore the #old-primary expectation to 12px. No downstream migration or broader radius redesign is needed.

Prior findings and validation limits

• The explicit-ID Textarea correction is present, with label-focus/ref/controlled-edit coverage. Invalid Input/Textarea boundaries now consume the corrected foundation danger role. The reset patch and regression cases are present; independent review found no additional demonstrated blocking reset defect, with ESM/CJS additions and patch-lock references consistent.
• Source-only review on the pinned Blox object store, including wrappers, style entrypoints, compatibility consumers, changed tests and the dependency patch. Existing exact-head CI snapshot: 12/12 checks successful. I did not execute repository code/tests or reproduce browser/desktop behavior. Installed upstream Base UI implementation details outside the patch context remain a validation limit; this is not a blanket runtime certification of reset semantics.
• Choice-invalid border styling is not an additional blocker: no governing requirement establishes a mandatory red outline, and Field provides error text. Downstream host form adoption remains outside stack 2/4.

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: the prior P2 compatibility defect remains

Reviewed afc4de9a603178442aa4f16d0e884043586cfe43 against exact stacked base a8deea467f5d6c5700d61f7aa76fdce61814301a (PR #85), not main. This refresh preserves the previously reviewed PR-specific files; it does not fix the finding from review 5272664839.

P2: Isolate the new control radius from unmigrated host controls

src/shared/design-system/styles/tokens.css:641 still changes --radius-control from var(--corner-control) (12px at the default root size) to 0.5rem (8px). The unchanged host aliases still point to that shared value:

• src/shared/styles/tokens.css:46: --radius-legacy-control: var(--radius-control).
• src/shared/styles/globals.css:56: --radius-xl: var(--radius-control).

Consequently, the new shared-control geometry also reaches the native-control recipes and legacy rounded-xl utilities. Real consumers include the profile inputs at src/features/communities/ProfileFields.tsx:24,38 and plugin-folder choices at src/app/PluginImport.tsx:190. This contradicts the retained compatibility contract at docs/design-system.md:138–145, rather than merely reflecting the intended 8px shared-control design.

The existing browser case “compiled host preserves compatibility utility meanings” contains the reproduction: #old-primary uses rounded-xl, but this PR changes its expected radius from 12px to 8px (tests/browser/appearance.spec.mjs:276–279). That accepts the compatibility change instead of guarding against it.

Same smallest fix and exit criteria: preserve the shared 8px radius; point --radius-legacy-control at the retained --corner-control, route the legacy --radius-xl through that legacy radius, and restore the #old-primary expectation to 12px. No downstream migration or radius redesign is required.

Re-review scope and validation

Two complementary source-only lanes completed on the pinned Blox object store. The PR-specific changed files match the previous reviewed head; the Textarea identity correction, corrected invalid-field role, and reset patch/regressions remain unchanged. No additional blocking reset or field-identity defect was established, and those accepted paths were not broadly re-reviewed.

Existing hosted CI is 12/12 successful at this exact head. No repository code was checked out, installed, built, tested, imported or executed during this review. The CSS chain and changed assertion above are source evidence, not a new browser measurement or desktop acceptance. No approval, dismissal or merge was performed.